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REMARKS/ARGUMENTS 



Drawings 

The Examiner has not indicated in the Office Action Summary (Item 10) whether the 
drawing have been accepted or objected to by the Examiner. The Examiner is requested to 
indicate that the drawings have been accepted. 

Claim Esisstiaas Under 35 yACJJflj&Q 

The Examiner has rejected pending claims 1-45. The Examiner rejected claims 1, 10-14, 
23-27, 36-39 under 35 U.S.C. 1 03(a).as being unpatentable over Xu (US 6,324,581) in view of 
Enoki (US 5,873,085). Claims 2-5, 9, 15-1 8, 22, 28-31 have been rejected under 35 U.S.C. 
1 03(a) as being unpatentable over Xu in view of Enoki and in view of Whidby (US patent 
publication No. 2003/01 10264 Al). Claims 6-18, 19-21, and 32-34 have been rejected under 35 
U,S.C 103(a) as being unpatentable over Xu, in view of Enoki, and in view of Porcar ("File 
Migration in Distributed Systems" California Univ., Berkeley, Lawrence, Berkeley Lab, 
copyright 1982, pages 1 14-135). Claims 40-45 have been rejected under 35 U.S.C 103(a) as 
being unpatentable over Xu, in view of Enoki, in view of Whidby, and in view of Porcar. 
Applicants traverse the rejections of pending claims 1-45. 

The Applicants had conducted an interview with the Examiner before preparing the 
current response. 

Amended Independent claims L 14. and 27 

Independent claims 1, 14, 27 are for controlling and providing access to a file to a remote 
computer over a network, and require: 

maintaining metadata about files maintained at remote storage 
locations; 
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receiving a request, at a server, from the remote computer over the network, wherein the 
request includes a filename corresponding to a requested file; 

determining from the metadata, by the server, one remote storage location address 
associated with the filename where the requested file is located; 

updating, by the server, the metadata for the requested file; and 

sending, by the server, the one remote storage location address to the remote computer, 
wherein the one remote storage location address where the requested file is located is more 
proximate to the remote computer than to the server. 

The Examiner rejected the claims 1 , 1 4, 27 as being unpatentable over Xu (col. 3, lines 
61 -66, col. 9: lines 59-63; col 10: lines 12-25) in view of Enoki (Abstract; Fig 1, reference 
numeral 109c; col. 13, line 59 ~ col. 14, line 32). Applicants traverse. 

The claims require that the one remote storage location address where the requested file is 
located be more proximate to the remote computer than to the server and nowhere does the cited 
Xu or the cited Enoki teach or suggest the claim requirement that the one remote storage location 
address where the requested file is located be more proximate to the remote computer than to the 
server. 

The Examiner has mentioned in Page 3 of the Office Action, that cited Enoki (Abstract; 
Fig 1, reference numeral 1 09c; col. 13, line 59 - coL 14, line 32) discloses the claim requirements 
that the one remote storage location address where the requested file is located be more 
proximate to the remote computer than to the server. Applicants respectfully submit that the 
cited Enoki does not teach or suggest the claim requirements that the one remote storage location 
address where the requested file is located be more proximate to the remote computer than to the 
server. 

The Examiner cited Abstract of the cited Enoki discusses a file management system with 
a plurality of servers and a plurality of terminals that share file services provided by the plurality 
of servers. A management table manages files stored in the plurality of servers by using virtual 
file identifiers. A request analyzing section checks the management table by using the virtual file 
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identifier contained in a file access request from a terminal and determines the server where the 
real data of the requested file is stored. 

The Examiner cited reference number 109c of FIG- 1 of the cited Enoki is a client 
computer from which requests are made over the network U 1 of the cited Enoki to server 
computers. 

The Examiner cited col. 13, line 59 - col. 14, lines 32 of the cited Enoki discusses "the 
processing flow in the server computer 101a in which the virtual file management apparatus 102 
is operating. First, the receiving section 107 receives a file access request from the client 
computer 109a (step S201). Next, the request analyzing section 106 checks the virtual file 
identifier contained in the received file access request, and determines the corresponding server 
computer name lOlaor 101b by referencing the management table 103 (step S202). Next, using 
data in the management table 103, the request modification processing section 1 10 first modifies 
the file access request into a file access request such that the server computer 101a or 101b 
determined by the request analyzing section 106 can directly respond to the client computer 109a, 
and then instructs the transmitting section 108 to transmit the modified file access request to the 
server computer 101a or 101 b (step S203). The transmitting section 1 08 then transmits the file 
access request to the server computer 1 01 a or 1 01b (step S204). The request processing section 
105 in the server computer 101a or 1 01b that received the modified file access request creates 
response data to the file access request by using the file system 104a or 104b, and transmits the 
response data to the client computer 1 09a." 

Therefore the cited Enoki discusses that on receiving a request from a client computer a 
determination is made to select a server computer for responding to the request from the client 
computer. However, nowhere does the cited Enoki teach or suggest the claim requirement that 
the one remote storage location address where the requested file is located is more proximate to 
the remote computer than to the server. 

For example, in the Examiner cited FIG, 1 of the cited Enoki, there are two server 
computers 101a and 101b, where the server computer 101a has a management table 103. While a 
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client computer may make a request to the server computer 101 a, the management table in the 
server computer 1 Ola may be used to indicate that the request be satisfied from the file system of 
the server computer 10tb. hi the cited Enoki, the server computers 101a and 10lb are coupled by 
a network to the client computers 109a, 1.09b, 109c However, there is no teaching or suggestion 
in the cited Enoki of the claim requirement that the one remote storage location address where 
the requested file is located is more proximate to the remote computer than to the server. The 
determination by the management table 103 of the cited Enoki of selected server computer to 
return the response to client is not based on the proximity of the selected server computer to the 
client that made the request. 

Should the Examiner maintain the rejection, the Examiner is requested to indicate which 
lines of the cited Enoki or the cited Xu teach or suggest the claim requirement that the one 
remote storage location address where the requested file is located is more proximate to the 
remote computer than to the server. The servers are merely coupled to the clients over a network 
in the cited Enoki. 

Addi tionally, the Examiner has modified the teachings of the cited Xu with the teachings 
of the cited Enoki to arrive at the claim requirements- The Examiner has mentioned that the 
motivation to minimize delay time for a data access request would motivate locating the one the 
one remote storage location address more proximate to the remote computer than to the server. 
Applicants submit that the Examiner's modification of the cited Xu with the teachings of the 
cited Enoki is improper because of the following reasons: 

(a) The cited Xu discusses sending a request for metadata (Xu: col. 10, lines 12-14) from a client 
to a data mover of the file server. The data mover of the file server returns the metadata to the 
client. The client uses the metadata to formulate a read or write request to a file system, where 
the file server includes the file system (Xu: col. 9, lines 60-62) in a cached disk array. The client 
may write new file attributes to the data mover. The claims require that the one remote storage 
location address where the requested file is located be more proximate to the remote compxiter 
than to the server. The cited Xu discusses, that the file is located in the file system (Xu: FIG. 3, 
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reference numeral 62) where the file server includes the file system (Xu: col. 9, lines 60-62) in a 
cached disk array. Therefore, in the cited Xu the file is located in the server. Since the file is 
located in the server, in the cited Xu the file is more proximate to the server than to the remote 
computer and the cited Xu teaches away from the claim requirement of the one remote storage 
location address where the requested file is located being more proximate to the remote computer 
than to the server. Since the cited Xu teaches away from the claim requirement of the one remote 
storage location address where the requested file is located being more proximate to the remote 
computer than to the server, the teachings of the cited Enoki cannot be used to modify the 
teachings of the cited Xu to arrive at the claim requirements that the one remote storage location 
address where the requested file is located being more proximate to the remote computer than to 
the server. The modification being suggested by the Examiner would make the system of the 
cited Xu inoperable as the file would no longer be located in the file system (Xu: FIG. 3, 
reference numeral 62) where the file server includes the file system (Xu: col 9, lines 60-62) in a 
cached disk array. Instead, the file would be located elsewhere in some other server and this 
would be contrary to the teachings of the cited Xu, and the system of the cited Xu would not be 
able to respond to the requests from the client. 

(b) The motivation provided by the Examiner that there would be reduction in traffic on a WAN 
and a minimization of the delay time for data access requests is improper. Reduction in traffic on 
a WAN and a irrinimizatioii of the delay time for data access requests could be achieved by 
storing the requested file in the client itself without making any requests to any server. 
Alternately, reduction in traffic on a WAN and a minimization of the delay time for data access 
requests could be achieved by determining least congested paths and directing 
files through these least congested paths. The motivation provided by the Examiner of reduction 
in traffic on a WAN and a minimization of the delay time for data access requests is improper 
because this motivation could lead to many different results and not to the claim requirements. 

Additionally, the Examiner has in his office action not addressed the argument provided 
by the Applicants in the previous response that the claims require the server to update the 
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metadata for the requested file and that the Examiner cited Xu discusses that the client may write 
new file attributes to the data mover of the server (Xu; col. 10: lines 20-22). Nowhere does the 
cited Xu teach or disclose the claim requirement of the server updating the metadata for the 
requested file. 

For the above reasons, claims 1,14, and 27 are patentable over the cited art. 

Independent Claims 10. 23. 36 

Independent claims 10, 23, 36 are for accessing a file in a source code management 
system, and comprises: 

sending, from a client, a first request for * the file to a server; 

receiving, at the client, a storage location address containing the file in response to the 
first request, wherein the storage location address containing the file is located is more proximate 
to the client than to the server; 

sending, from the client, a second request to the storage location address; and 

receiving, at the client, an access to the file from the storage location address. 

The Examiner has rejected claims 10, 23, 36 as being unpatentable over Xn (col 3, lines 
61-65, col. 10: lines 12-22) in view of Enoki (Abstract; Fig 1, reference numeral 109c; col. 13, 
line 59 - col. 14, line 32). Applicants traverse. Applicants traverse. 

The claims require that the one remote storage location address where the requested file is 
located be more proximate to the remote computer than to the server and nowhere does the cited 
Xu or the cited Enoki teach or suggest the claim requirement that the one remote storage location 
address where the requested file is located be more proximate to the remote computer than to the 
server. 

The Examiner has mentioned in Page 3 of the Office Action, that cited Enoki (Abstract; 
Fig 1, reference numeral 109c; col 13, line 59 - coL 14, line 32) discloses the claim requirements 
tiiat the one remote storage location address where the requested file is located be more 
proximate to the remote computer than to the server. Applicants respectfully submit that the 
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cited Enoki does not teach or suggest the claim requirements that the one remote storage location 
address where the requested file is located be more proximate to the remote computer than to the 
server. 

The Examiner cited Abstract of the cited Enoki di scusses a file managem ent system with 
a plurality of servers and a plurality of terminals that share file services provided by the plurality 
of servers. A management table manages files stored in the plurality of servers by using virtual 
file identifiers. A request analyzing section checks the management table by using the virtual file 
identifier contained in a file access request from a terminal and determines the server where the 
real data of the requested file is stored. 

The Examiner cited reference number 109c of FIG. 1 of the cited Enoki is a client 
computer from which requests are made over the network 111 of the cited Enoki to server 
computers. 

The Examiner cited col. 13, line 59 - coL 14, lines 32 of the cited Enoki discusses "the 
processing flow in the server computer 101 a in which the virtual file management apparatus 102 
is operating. First, the receiving section 107 receives a file access request from the client 
computer 1 09a (step S201). Next, the request analyzing section 106 checks the virtual file 
identifier contained in the received file access request, and determines the corresponding server 
computer name 101a or 101b by referencing the management table 103 (step S202). Next, using 
data in the management table 1 03, the request modification processing section 1 1 0 first modifies 
the file access request into a file access request such that the server computer 101a or 1 01b 
determined by the request analyzing section 106 can directly respond to the client computer 109a, 
and then instructs the transmitting section 108 to transmit the modified file access request to the 
server computer 101 a or 101b (step S203). The transmitting section 108 then transmits the file 
access request to the server computer 1 Ola or 101b (step S204). The request processing section 
105 in the server computer 1 01 a or 101 b that received the modified file access request creates 
response data to the file access request by using the file system 104a or 1 04b, and transmits the 
response data to the client computer 109a," 
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Therefore the cited Enoki discusses that on receiving a request from a client computer a 
determination is made to select a server computer for responding to the request from the client 
computer. However, nowhere does the cited Enoki teach or suggest the claim requirement that 
the one remote storage location address where the requested file is located is more proximate to 
the remote computer than to the server. 

For example, in the Examiner cited FIG. 1 of the cited Enoki, there are two server 
computers 101a and 101b, where the server computer 101a has a management table 103. While a 
client computer may make a request to the server computer 101a, the management table in the 
server computer 101a maybe used to indicate that the request be satisfied from the file system of 
the server computer 101b. In the cited Enoki, the server computers 101a and 101b are coupled by 
a network to the client computers 109a, 109b, 1 09c. However, there is no teaching or suggestion 
in the cited Enoki of the claim requirement that the one remote storage location address where 
the requested file is located is more proximate to the remote computer than to the server. The 
determination by the management table 103 of the cited Enoki of selected server computer to 
return the response to client is not based on the proximity of the selected server computer to the 
client that made the request. 

Should the Examiner maintain the rejection, the Examiner is requested to indicate which 
lines of the cited Enoki or the cited Xu teach or suggest the claim requirement that the one 
remote storage location address where the requested file is located is more proximate to the 
remote computer than to the server. The servers are merely coupled to the clients over a network 
in the cited Enoki. 

Additionally, the Examiner has modified the teachings of the cited Xu with the teachings 
of the cited Enoki to arrive at the claim requirements. The Examiner has mentioned that th e 
motivation to minimize delay time for a data access request would motivate locating the one the 
one remote storage location address more proximate to the remote computer than to the server. 
Applicants submit that the Examiner's modification of the cited Xu with the teachings of the 
cited Enoki is improper because of the following reasons: 
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(a) The cited Xu discusses sending a request for metadata (Xu: col. 10, lines 1.2-14) from a client 
to a data mover of the file server. The data mover of the fi le server returns the metadata to the 
client. The client uses the metadata to formulate a read or write request to a file system, where 
the file server includes the file system (Xu: col. 9, lines 60-62) in a cached disk array. The client 
may write new file attributes to the data mover. The claims requite that the one remote storage 
location address where the requested file is located be more proximate to the remote computer 
than to the server. The cited Xu discusses that the file is located in the file system (Xu: FIG. 3, ' 
reference numeral 62) where the file server includes the file system (Xu: col. 9, lines 60-62) in a 
cached disk array. Therefore, in the cited Xu the file is located in the server. Since the file is 
located in the server, in the cited Xu the file is more proximate to the server than to the remote 
computer and the cited Xu teaches away from the claim requirement of the one remote storage 
location address where the requested file is located being more proximate to the remote computer 
than to the server. Since the cited Xu teaches away from the claim requirement of the one remote 
storage location address where the requested file is located being more proximate to the remote 
computer than to the server, the teachings of the cited Enoki cannot be used to modify the 
teachings of the cited Xu to arrive at the claim requirements that the one remote storage location 
address where the requested file is located being more proximate to the remote computer than to 
the server. The modification being suggested by the Examiner would make the system of the 
cited Xu inoperable as the file would no longer be located in the file system (Xu: FIG. 3, 
reference numeral 62) where the file server includes the file system (Xu: col. 9, lines 60-62) in a 
cached disk array. Instead, the file would be located elsewhere in some other server and this 
would be contrary to the teachings of the cited Xu, and the system of the cited Xu would not be 
able to respond to the requests from the client. 

(b) The motivation provided by the Examiner that there would be reduction in traffic on a WAN 
and a minimization of the delay time for data access requests is improper. Reduction in. traffic on 
a WAN and a minimization of the delay time for data access requests could be achieved by 
storing the requested file in the client itself without making any requests to any server. 
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Alternately, reduction in traffic on a WAN and a minimization of the delay time for data access 
requests could be achieved by detennining least congested paths and directing 
files through these least congested paths. The motivation provided by the Examiner of reduction 
in traffic on a WAN and a minimization of the delay time for data access requests is improper 
because this motivation could lead to many different results and not to the claim requirements. 
For the above reasons claims 10, 23, and 36 are patentable over the cited art. 

Dependent claims 2-Q. 1 1 -1 3. 1 3-22. 24-26. 28-35. 37^39 

The Examiner has also rejected pending claims 2-9, 1 1-13, 15-22, 24-26, 28-35, 37-39 
that depend on the pending independent claims 1, 14, 27, 10, 23, or 36. Applicants traverse these 
rejections. Applicants submit that these claims are patentable over the cited art because they 
depend from claims 1, 14, 27, 10, 23, or 36 which are patentable over the cited art for the reason 
discussed above, and because the combination of the limitations in the dependent claims 2-9, 1 1- 
13, 15-22, 24-26, 28-35, 37-39 and the base and intervening claims from which they depend 
provide further grounds of distinction over the cited art. 



Claims 3. 16. 29 

Claims 3, 16, 29 depend on dependent claims 2, 1 5, 28 respectively that depend from 
claims 1, 14, 27 respectively. Therefore, claims 3, 16, 39 include the following requirements in 
addition to the requirements of claims 1, 14, 27: (a) the remote computer is a source code 
management system client (b) the one remote storage location address identifies a storage device 
that is at a geographical location closer to the remote computer than a location of the metadata 
and (c)_the server that received the request from the remote computer directly communicates the 
one storage location address for retrieval of the requested file to the network for transmission to 
the remote computer, based on the received request. 
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The Examiner has rejected claims 3, 16, 29 wider 35 U.S.C 103(a) as being unpatentable 
over Xu, in view of Enoki, and further in view of Whidby, 

The claims require that the one remote storage location address identifies a storage device 
that is at a geographical location closer to the remote computer than a location of the metadata as 
this claim requirement is neither taught or suggested by the cited Xu, the cited Enoki, or the cited 
Whidby. 

The Examiner has mentioned in Page 1 1 of the Office Action, that cited Enoki (Abstract; 
Fig 1, reference numeral 109c; col. 13, line 59 - col. 14, line 32) discloses the claim requirements 
that the one remote storage location address identifies a storage device that is at a geographical 
location closer to the remote computer than a location of the metadata. 

The Examiner cited Abstract of the cited Enoki discusses a file management system with 
a plurality of servers and a plurality of terminals that share file services provided by the plurality 
of servers, A management table manages files stored in the plurality of servers by using virtual 
file identifiers. A request analyzing section checks the management table by using the virtual file 
identifier contained in a file access request from a terminal and determines the server where the 
real data of the requested file is stored. 

The Examiner cited reference number 109c of FIG. 1 of the cited Enoki is a client 
computer from which requests are made over the network 1 1 1 of the cited Enoki to server 
computers. 

The Examiner cited col 13, line 59 - col 14, lines 32 of the cited Enoki discusses "the 
processing flow in the server computer 101a in which the virtual file management apparatus 102 
is operating. First, the receiving section 107 receives a file access request from the client 
computer 109a (step S201). Next, the request analyzing section 106 checks the virtual file 
identifier contained in the received file access request, and determines the corresponding server 
computer name 101a or 101b by referencing the management table 103 (step S202). Next, using 
data in the management table 1 03, the request modification processing section 1 10 first modifies 
the file access request into a file access request such that the server computer 101a or 101b 
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determined by the request analyzing section 106 can directly respond to the client computer 109a, 
and then instructs the transmitting section 108 to transmit the modified file access request to the 
server computer 101a or 1 01b (step S203). The transmitting section 108 then transmits the file 
access request to the server computer 101a or 101b (step S204). The request processing section 
105 in the server computer 101a or 101b that received the modified file access request creates 
response data to the file access request by using the file system 104a or 104b, and transmits the 
response data to the client computer 109a." 

Therefore the cited Enoki discusses that on receiving a request from a client computer a 
determination is made to select a server computer for responding to the request from the client 
computer. However, nowhere does the cited Enokj teach or suggest the claim requirement that 
the one remote storage location address identifies a storage device that is at a geographical 
location closer to the remote computer than a location of the metadata. 

For example, in the Examin er cited FJG. 1 of the cited Enoki, there arc two server 
computers 101 a and 101b, where the server computer 101a has a management table 103. While a 
client computer may make a request to the server computer 101 a, the management table in the 
server computer 101a may be used to indicate that the request be satisfied from the file system of 
the server computer 101b. In the cited Enoki, the server computers 101a and 101b are coupled by 
a network to the client computers 1 09a, 109b, 1 09c. However, there is no teaching or suggestion 
in the cited Enoki of the claim requirement that the one remote storage location address identifies 
a storage device that is at a geographical location closer to the remote computer than a location of 
the metadata. The determination by the management table 1 03 of the cited Enoki of selected 
server computer to return the response to client is not based on the geographical location of the 
selected server computer to the client that made the request. 

Should the Examiner maintain the rejection, the Examiner is requested to indicate which 
lines of the cited Enoki or the cited Xu or the cited Whidby teach or suggest the claim 
requirements that the one remote storage location address identifies a storage device that is at a 
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geographical location closer to the remote computer than a location of the metadata. The servers 
are merely coupled to the clients over a network in the cited Enoki. 

Additionally the motivation provided by the Examiner (in page 20 of the office action) to 
modify the cited Xu with the teachings of the cited Enoki and the cited Whidby, that there would 
be an improvement in traffic on a WAN and a shortening of the delay time for data access 
requests is improper. Improvement in traffic on a WAN and a shortening of the delay time for 
data access requests could be achieved by storing the requested file in the client itself without 
making any requests to any server. Alternately, improvement in traffic on a WAN and a 
shortening of the delay time for data access requests could be achieved by determining least 
congested paths and directing files through these least congested paths. The motivation provided 
by the Examiner of improvement in traffic on a WAN and a shortening of the delay time for data 
access requests is improper because this motivation could lead to many different results and not 
to the claim requirements that the one remote storage location address identifies a storage device 
that is at a geographical location closer to the remote computer than a location of the metadata. 

Additionally, using the cited Whidby and the cited Enoki to modify the system of the 
cited Xu to arrive at the claim requirements of claims 3, 16, 29 would render the system of the 
cited Xu inoperable because the source code would be distributed across multiple servers in the 
system of cited Xu, and the version control method of the cited Whidby could not be applied to 
the system of the cited Xu. 

If as the Examiner indi cates the system of the cited Xu were modified with the teachings 
of the cited Whidby, then the system of the cited Xu would have files distributed in a plurality of 
server nodes and a geographically closer would have to be selected for a response from a client. 
The version control discussed in the cited Whidby cannot be used to modify the system of the 
cited Xu where the files are distributed in a plurality of server nodes and a geographically closer 
server would have to be selected for a response from a client. In such as case, the geographically 
closer node would also have to maintain the most current version of the requested file as is the . 
case in a source code management system and such teachings or suggestions are not provided in 
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the cited Xu, the cited Whidby or the cited Enoki. Returning a file from the geographically 
closer server computer to the client arrived at by modifying the cited Xu with the cited Enoki 
maybe allow the sending of the correct version of the file in a version control system (i.e., not 
implement a source code management system) if the version control system of the cited Whidby 
were used to modify the system of the cited Xu. Therefore modifying the cited Xu with the cited 
Whidby and the cited Enoki does not teach or suggest the claim requirements that (a) the remote 
computer is a source code management system client (b) the one remote storage location address 
identifies a storage device that is at a geographical location closer to the remote computer than a 
location of the metadata and (cXthe server that received the request from the remote computer 
directly communicates the one storage location address for retrieval of the requested file to the 
network for transmission to the remote computer, based on the received request. 
For the above reasons, claims 3, 16, 29 are patentable over the cited art* 

Clams M7, 30 

Claims 4, 1 7, 20. depend on claims 3, 16, 29 respectively, wherein the request is for 
checking-out the requested file corresponding to the filename, and further comprising: 
locking the requested file; 

returning a response code to the remote computer indicating that file check-out is 
successful; and 

updating the metadata indicating that the requested file is checked-out and locked. 

The Examiner has rejected claims 4, 17, 30 tinder 35 U.S.C, 103(a) as being unpatentable 

over Xu, in view of Enoki, and further in view of Whidby. 

Nowhere does the Examiner cited Xu (col. 9, lines 59 - col. 10, lines 25) [or the cited 

Enoki or the cited Whidby] teach or suggest the following claim requirements: 

(a) returning a response code to the remote computer indicating that file check-out is successful 

(b) updating the metadata indicating that the requested file is checked-out and locked. 
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The cited Xu discusses that the data mover responds by placing an appropriate lock on the 
file to be accessed and returning metadata to the client. Should the Examiner maintain the 
rejection the Examiner is requested to indicated where the cited Xu (or the cited Enoki, or the 
cited Whidby) teach or suggest the claim requirement of: 

(a) returning a response code to the remote computer indicating that file check-out is successful 

(b) updating the metadata indicating that the requested file is checked-out and locked. 

For the above reasons claims 4, 17, 30 are patentable over the cited art. 

Claims 5, 18,31 

Claims 5, 18, 31 depend on claims 3, 16, 29 respectively, wherein the request is for 
checking-in the requested file corresponding to the filename, and fiirther comprising: 
updating the metadata indicating the requested file is unlocked; and 
returning a response code indicating that the file check-in is successful 
Nowhere does the Examiner cited Xu (col. 1 0, lines 1 7-25) [or the cited Enoki or the 
cited Whidby] teach or suggest the following claim requirements: 

(a) updating the metadata indicating the requested file is unlocked; 

(b) returning a response code indicating that the file check-in is successful. 

The Examiner cited col. 10, lines 17-25 of the cited Xu discusses placing appropriated 
locks on the file to be accessed, and returning metadata including pointers to where the data to be 
accessed is stored in the file system. The client may write the new file attributes to the data 
mover after the data is written to the file system. 

Should the Examiner maintain the rejection of the claims* the Examiner is requested to 
indicated where the cited Xu (or the cited Enoki, or the cited Whidby) teach or suggest the claim 
requirements of: 

(a) updating the metadata indicating the requested file is unlocked; 

(b) returning a response code indicating that the file check-in is successful. 

For the above reasons claims 5, 18, 31 are patentable over the cited art. 
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Claims 6, 19. 32 

Claims 6, 19, 32 depend on claims 1, 14, 27 respectively and further require: 
The method of claim 1, further comprising: 

processing a pattern of requests for the requested file received from remote computers at 
different geographical locations; 

determining a plurality of remote storage locations based on the pattern of requests for the 
requested file; 

storing the requested file corresponding to the filename at the determined plurality of 
remote storage locations; and 

saving a correspondence between the requested file and storage location addresses 
corresponding to the determined plurality of remote storage locations in the metadata. 

The Examiner has rejected claims 6, 19, 32 as being unpatentable under 35 U.S.C. 103(a) 
as being unpatentable over Xu in view of Enoki and Porcar. Applicants traverse. 

The claims require: 

(a) determining a plurality of remote storage locations based on the pattern of requests for the 
requested file; 

(b) storing the requested file corresponding to the filename at the determined plurality of remote 
storage locations; 

and these requirements are not taught or suggested by the cited Porcar (Chapter 5: summary; 
section 52 Migration Policies; section 5.3 Experimental results). 

The cited Porcar discusses file migration in distributed computer systems that maintain 
multiple copies of files. Files are moved around in a distributed computer system based on 
certain policies in response to the referencing of files, such as updates of files. 

The claims require determining a plurality of remote storage locations based on the 
pattern of requests for the requested file and storing the requested file corresponding to the 
filename at the determined plurality of remote storage locations. The cited Porcar teaches away 
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from the claim requirements because the cited Porcar maintains the master copy as local to the 
user updating the file (cited Porcar: page 121, line 19 included the third paragraph of page 121 

that starts with "As we described in section 5.1.1 " ). In page 1 1 7 it is indicated in the cited 

Porcar in 5.1 .1 . that "for each file, there is at least one copy, the master copy, in the system at all 

times In our implementation, the master copy is never deleted". As described above the 

master copy is local to the user updating the file, i.e., the master copy is local to the remote 
computer. Therefore, the master copy and the distribution of the master copy teaches away from 
the claim requirements of determining a plurality of remote storage locations based on the pattern 
of requests for the requested file and storing the requested file corresponding to the filename at 
the determined plurality of remote storage locations. 

Should the Examiner maintain the rejection the Examiner should indicate which elements 
of the cited Porcar corresponds to: (A) the requested file of the claim requirements; and (B) the 
plurality of storage locations where the requested file is stored, and which lines of the cited 
Porcar teaches or suggests the claim requirements of (I), determining a plurality of remote storage 
locations based on the pattern of requests for the requested file; (II) storing the requested file 
corresponding to the filename at the determined plurality of remote storage locations. 

Additionally, the motivation of the cited Porcar of reducing the traffic an order of 
magnitude as compared to single copy policies (Porcar 5.4 conclusions^used by the Examiner to 
modify the system of the cited Xu with the teachings of the cited Porcar is improper. The 
reduction of traffic in the cited Porcar is caused by the removal of "copies that exceed a retention 
cost based on storage costs and update traffic costs" (cited Porcar, page 134). Therefore, the cited 
Porcar is m otivating reduction of traffic by removing copies of files. If copies of files are 
removed in the system of the cited Xu then when requests are made to the data movers of the 
cited Xu the requests from the client cannot not be satisfied and the system of the cited Xu would 
be inoperable. Therefore, modifying the system of the cited Xu according to the motivation 
provided by the cited Porcar is improper as it would lead to an inoperable system in the cited Xu. 

For the above reasons, claims 6, 19, and 32 are patentable over the cited art. 
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Claims 7, 20, 33 depend on claims 6, 19, 32 respectively, wherein one determined remote * 
storage location is at a geographical location that is more proximate to the remote computer 
having more requests for the requested file than other remote computers. 

The cited Porcar (section 5.1 .6 distributing the updates) used in rejecting the claim 
requirements discusses that when a master copy has been updated, the remaining copies are 
brought up to date by transmitting all updates in a batch. Reads to local copies are made 
inexpensive. Files arc synchronized. A weighted voting mechanism and file version numbers are 
used to decide what arc the files that contain current information. Nowhere does the cited Porcar 
teach or disclose the claim requirement that the one determined remote storage location is at a 
geographical location that is more proximate to the remote computer having more requests for 
the requested file than other remote computers. 

Additionally, there is no motivation provided by the Examiner to combine the teachings 
or suggestions of the cited Porcar, the cited Xu and the cited Enoki to arrive at the claim 
requirements of claims 7, 20 3 33. 

For the above reasons claims 7, 20, 33 are patentable over the cited art. 

filaimsA 21 34 

Claims 8, 20, 33 depend on claims 6, 19, 32 respectively, wherein one determined remote 
storage locati on is selected from the plurality of remote storage locations to minimize a distance 
the requested file is transmitted between each remote computer and the one determined remote 
storage location based on the number of requests for the file from each remote computer. 

The cited Porcar (section 5.2 Migration policies) used in rejecting the claim requirements 
discusses migration policies for files in a distributed system based on an extension of the space 
time working set policy (Porcar: page 1 23) The space time working set policy removes any copy 
based on fetching costs to storage costs, and a ratio of update communications to storage costs. 
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Nowhere does the cited Porcar teach or suggest the claim requirement that the one determined 
remote storage location is selected from the plurality of remote storage locations to minimize a 
distance the requested file is transmitted between each remote computer and the one determined 
remote storage location based on the number of requests for the file from each remote computer. 

Additionally, there is no motivation provided by the Examiner to combine the teachings 
or suggestions of the cited Porcar, with the cited Xu and the cited Enoki to aixi ve at the claim 
requirements, of claims 8, 20, 33. 

For the above reasons claims 8, 21, 34 are patentable over the cited art. 

Claimql?. 26,3? 

Claims 13, 26, 39 depend on claim 10, 23, 36 respectively and further require: 
receiving a first response code from the server in response to the first request; and 
receiving a second response code from the storage location in response to the second 
request. 

The cited Xu (col. 10 t lines 14-19) discusses locking, returning metadata, writing new file 
attributes, etc. Nowhere does the cited Xu teach or suggest the claim requirement of receiving a 
firet response code from the server in response to the first request; and receiving a second 
response code from the storage location in response to the second request- 
Should the Examiner maintain the rejection of the claims the Examiner is requested to 
indicate which element of the cited Xu corresponds to: 

(a) a first response code 

(b) a first request 

(c) a second response code 

(d) a second request. 

For the above reasons claims 13, 26, 39 arc patentable over the cited art 

glaims 40. 42.44 
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Claims 40, 42, 44 depend on claims 1, 14, 27 respectively and further require that the 
remote computer be a source code management system client, wherein the metadata is kept more 
proximate to the server than to the source code management system client, wherein the server 
communicates the one storage location address to the network for transmission to the source code 
management system client, and wherein tbe one storage location is determined by the server 
based on a history of request patterns from a plurality of source code management system clients. 

Claims 40, 42, 44 have been rejected under 35 U.S.C 1 03(a) as being unpatentable over 
Xu, in view of Enoki, in view of Whidby, and in view of Porcar. 

The Examiner has indicated that FIG. 1 8 of die cited Xu teaches or suggests that the 
metadata is kept more proximate to the server than to the cli ent FIG- 18 of the cited Xu shows 
that the metadata 332 is more proximate to data mover #2 than to data mover #1. However the 
data mover #1 and data mover #2 of the cited Xu are both servers and neither are clients. The 
clients of the cited Xu arc client #1 and client #2 (reference numeral 46 and 47, figure on cover 
page of the cited Xu). Therefore the cited Xu does not teach or suggest the claim requirements 
that the metadata is kept more proximate to the server than to the source code management 
system client 

Additionally, the motivations provided by the Examiner to modify the system of the cited 
Xu with the teachings of the cited Whidby* Enoki and Porcar are not proper. The motivation 
provided by the Examiner are as follows: 

(a) elimination of the need for the developer to perform version management on the files (to 
modify the cited Xu with the cited Whidby) 

(b) easy way of optimizing file handling mechanisms (to modify the cited Xu with the cited 
Porcar) . 

Eliminating the need for the developer to perform version management on the files is a 
general characteristic of any source code management system, and many different types of source 
code management system may be constructed based on such motivations, and such general 
motivations that lead to many different alternative systems may not be used to reject the specific 
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claim requirements. Similarly, optimizing file handling mechanisms in an easy way can lead to 
many different solutions, for example, files can be placed based on network traffic patterns or 
directly at the client, and do not specifically motivate combining the claim requirements of the 
one storage location being determined by the server based on a history of request patterns from a 
plurality of source code management system clients to modify the system of the cited Xu to 
arrive at the claim requirement. 

For the above reasons, claims 40, 42, and 44 are patentable over the cited art. 

Claims 41. 43. 45 

Claims 41, 42, 45 depend on claims 10, 23, 36 respectively, wherein the client is a source 
code management system client, wherein metadata corresponding to the file is kept more 
proximate to the server than to the source code management system client, wherein the server 
communicates the storage location address to the network for transmission to the source code 
management system client, and wherein the storage location is determined by the server based cm 
a history of request patterns from a plurality of source code management system clients. 

Claims 41, 43, 45 have been rejected under 35 U.S.C. 103(a) as being unpatentable over 
Xu, in view of Enoki, in view of Whidby, and in view of Porcar. 

The Examiner has not indicated where the cited Xu teaches or suggests the claim 
requirement that the metadata is kept more proximate to the server than to the client. In other 
parts of the office action (e.g., in the rejection of claims 40, 42, 44), the Examiner has indicated 
that FIG. 18 of the cited Xu teaches or suggests that the metadata is kept more proximate to the 
server than to the client. FIG. 18 of the cited Xu shows that the metadata 332 is more proximate 
to data mover #2 than to data mover #1 . However the data mover #1 and data mover #2 of the 
cited Xu are both servers and neither are clients. The clients of the cited Xu are client #1 and 
client #2 (reference numeral 46 and 47, figure on cover page of the cited Xu). Th erefore the cited 
Xu does not teach or suggest the claim requirements that the metadata is kept more proximate to 
the server than to the source code management system client. 



Page 33 of 35 



PAGE 36/38* RCVD AT 6/21/2005 11:08:4/ PM [Eastern Daylight Time] * SVR:USPT0-EFXRM/2 * DNIS:8729306 * CSfD:3105567984 * DURATION (mm-ss):11-38 



"06/21/2085 20:12 3105567984 



KONRAD RAYNES VICTOR 



PAGE 37/38 



Amdt dated June 21, 2005 

Reply to Office action of 04/21/2005 



Serial No. 10/038,165 
Docket No. TUC920O10O5SUS1 
FirmNo. 0018.0102 



Additionally, the motivations provided by the Examiner to modify the system of the cited 
Xu with the teachings of the cited Whidby, Enoki and Porcar are not proper- The motivation 
provided by the Examiner are as follows: 

(a) elimination of the need for the developer to perform version management on the files (to 
modify the cited Xu with the cited Whidby) 

(b) easy way of optimizing file handling mechanisms (to modify the cited Xu with the cited 
Porcar) . 

Eliminating the need for the developer to perform version management on the files is a 
general characteristic of any source code management system, and many different types of source 
code management system may be constructed based on such motivations, and such general 
motivations may not be used to reject the specific claim requirements- Similarly, optimizing file 
handling mechanisms in an easy way can lead to many different solutions, for example, files can 
be placed based on network traffic patterns or directly at the client, and do not specifically 
motivate combining the claim requirements of the one storage location being determined by the 
server based on a history of request pattern s from a plurality of source code management system 
clients to modify the system of the cjted Xu to arrive at the claim requirement. 

For the above reasons, claims 41, 43, 45 are patentable over the cited art. 



For all the above reasons, Applicant submits that the pending claims are patentable over 
the art of record. Applicants have indicated appropriate fees. Nonetheless, should any additional 
fees be required, please charge Deposit Account No, 09-0449. 

The attorney/agent invites the Examiner to contact him at (310) 557-2292 if the 
Examiner believes such contact would advance the prosecution of the case. 



Conclusion 



Dated: June 2L 2005 




Rabindranath Dutta 
Registration No. 51,010 
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Please direct all correspondences to: 

Rabindranath Dutta 

Konrad Raynes & Victor, LLP 

315 South Beverly Drive, Ste. 210 

Beverly Hills, CA 90212 

Tel: 310-557-2292 

Fax: 310-556-7984 
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